In a conventional method, a series of tasks that an information processing apparatus is caused to execute is executed automatically as a workflow. The workflow is a series of work procedures defined by combining tasks each of which is an operation of an OS or middleware (application). For example, a series of tasks that are defined as a workflow for monitoring or maintenance work are automatically executed at a data center in which a large number of IT devices (servers, storage devices, networks, etc.) are installed and in which a plurality of work systems each configured with an operating system (OS), middleware, and an application is run.
General run book automation (RBA) products that automate operational work in data centers provides a script execution environment that does not depend on the OS and also provides a means for creating work tasks corresponding to work by using the functions provided by the OS, such as file operations, irrespective of the type of the OS and for automating the work tasks.
It is known that, with the exception of an OS, for example, for the execution of operations on middleware, a workflow is created by combining work tasks for the execution of operations on each middleware product. In this case, by creating a script that absorbs the different in operations between middleware, the operations may be made logical and accordingly the middleware may be caused to run in a different environment by using the same workflow.
Examples of such techniques are disclosed in Japanese Laid-open Patent Publication No. 2006-277535, Japanese Laid-open Patent Publication No. 10-27203, and Japanese Laid-open Patent Publication No. 10-214289.
However, for example, when a workflow (definition of the operational work procedures) that has been tested under a test environment is loaded in an actual real environment where real works are carried out, the system configuration or the roles of the server may be different in the test environment and the real environment. For example, even the same application server may have a role of executing a single work or a plurality of works.
For this reason, it is preferable to change the operational work procedure in consideration of the procedure for starting the server or the procedure for stopping the server in accordance with the dependencies between servers. For example, when the application (middleware) or the server is stopped for maintenance work, such as application of a patch, the effected area is different depending on the role of the server and thus the work tasks before and after the stopping of the server may be different. In order to accurately deal with the change, the workflow needs to be corrected manually.
In the conventional technology, the staff who manage workflows manually clarify the difference in the configuration (difference in the system configuration) between the test environment and the real environment and manually perform correction work on workflow definitions according to the real environment in which the workflow is installed.
Manually changing the definition may cause quality deterioration. Thus, by preparing an environment closer to the actual real environment as a test environment in a range that the cost allows, the range for manual correction may be reduced. However, bringing the test environment closer to the real environment causes an increase in IT costs.